home *** CD-ROM | disk | FTP | other *** search
/ Aminet 22 / Aminet 22 (1997)(GTI - Schatztruhe)[!][Dec 1997].iso / Aminet / util / boot / AllocP.readme < prev    next >
Text File  |  1997-11-02  |  7KB  |  198 lines
  1. Short:    AllocP - BetterAlloc (AllocMem/AllocVec patch) V2.01
  2. Author:   thor@math.tu-berlin.de 
  3. Uploader: thor@math.tu-berlin.de
  4. Version:  2.01
  5. Type:     util/boot
  6.  
  7. (with the friendly permission of the original author, Andreas Kleinert)
  8.  
  9. _____________________________________________________________________________
  10.  
  11. New in release 2.01:
  12.  
  13.     - Added a workarount for stupid "SaferPatches" clones.
  14.  
  15. _____________________________________________________________________________
  16.  
  17. New in release 2.00:
  18.  
  19.     - Rewritten in assembly language, much shorter file
  20.     - Tries a partial flush first, instead of removing
  21.       all libraries on failure.
  22.     - Removed unnecessary AllocVec patch since it calls
  23.       AllocMem anyways.
  24.  
  25. _____________________________________________________________________________
  26.  
  27. AllocP will be part of a major memory defragmentizer project still to be
  28. published, called PoolMem. Please stay tuned!
  29. _____________________________________________________________________________
  30.  
  31.  Sometimes programs fail with a "not enough memory" error,
  32.  but after calling "avail flush" the same operation does
  33.  succeed without problems.
  34.  
  35.  
  36.  If AllocMem routine in the ROMs did not find enough memory,
  37.  it tries to flush disk based libraries and devices and,
  38.  afterwards, tries again to reallocate the memory.
  39.  However, due to a design flaw of the AllocMem() routine,
  40.  this memory flushing does not have the desired result some-
  41.  times - even though the libraries have been informed to
  42.  remove themselves, the memory is not available directly
  43.  afterwards. The AllocMem() call will fail anyways, EVEN THOUGH 
  44.  the requiested memory will be available immediatly after completion 
  45.  of AllocMem().
  46.  The reasons for this strange behaiviour are rather technical 
  47.  and explained below, for the interested user.
  48.  
  49.  
  50.  This patch does ensure, that AllocMem/AllocVec won't
  51.  fail unless there's really no memory available, even
  52.  by flushing. This means:
  53.  
  54.     - less "out of memory" failures
  55.     - less "bad behaviour" of bad programs, which don't
  56.       check results of AllocMem/AllocVec
  57.     - no more need to call "avail flush" by hand
  58.       from the shell
  59.     - thus no more "retry" operations after "avail flush"
  60.     - no more unused libraries/devices consuming memory
  61.       when it is already low
  62.  
  63.  Note:  Works now for all operating systems and all CPUs,
  64.     is no longer restricted to V37 or MC'20.
  65.  
  66.  Usage:  Try starting in the Shell/CLI.
  67.          If it does run stable, copy it into
  68.          your C: directory and add it
  69.          somewhere into your s:user-startup
  70.  
  71.                 AllocP
  72.  
  73.  You use this patch at your own risk.
  74.  No guarantee for anything.
  75.  Source code in assembly language included, requires the DevPac assembler
  76.  and my macro package at dev/asm/DvPkMacros.lha at the AmiNet.
  77.  
  78.  
  79.  All mentioned trademarks are subject to their owners.
  80. _____________________________________________________________________________
  81.  
  82. The design flaw in AllocMem():
  83.  
  84.     When looking closely at the ROM routine of AllocMem(), you'll
  85.     notice that a memory flush is TRIED if the first allocation
  86.     failed. 
  87.     Why does AllocMem then fail, even though if enough memory
  88.     is available?
  89.  
  90.     Consider the following situation:
  91.     A library has launched a sub-task for control of some of its
  92.     features. This sub-task could be used for disk I-O, for example.
  93.  
  94.     If this hypothetical library has to be expunged, it can't do
  95.     this on its own because this will release memory of the sub-task
  96.     which is still running. This sub-task must be informed somehow
  97.     that its memory must go. While this is in principle simple to do -
  98.     just send a message to the sub task - the library can't wait for
  99.     an answer of the sub-task because this would brake the Forbid()
  100.     state, which is illegal at this point of the operation.
  101.     The only solution for the library is to leave the memory flush
  102.     to the sub task and to return to the low-memory handler of exec
  103.     WITHOUT trying to remove itself - leaving this to its sub-task.
  104.     
  105.     On the other hand, since multitasking is still forbidden, there
  106.     is NO chance that this subtask will actually get a chance to 
  107.     remove the library, leaving it in memory and causing the 
  108.     allocation failure. EVEN THOUGH the library was informed to
  109.     get removed, there is no chance of doing this while flushing.
  110.  
  111.     However, as soon as exec leaves the AllocMem routine, multi-
  112.     tasking will be turned on again, thus causing a task switch to
  113.     the subtask and NOW causing the removal of the library - to late
  114.     to have any effect.
  115.  
  116.     AllocP tries to avoid this situation by calling AllocMem a
  117.     second time.
  118.  
  119.  
  120. _____________________________________________________________________________
  121.  
  122.                         The THOR-Software Licence
  123.  
  124.  
  125. This License applies to the computer programs known as "AllocP".
  126. The "Program", below, refers to such program.
  127.  
  128.  
  129. The programs and files in this distribution are freely distributable
  130. under the restrictions stated below, but are also Copyright (c)
  131. Thomas Richter.
  132.  
  133.  
  134. Distribution of the Program by a commercial organization without written
  135. permission from the author to any third party is prohibited if any payment
  136. is made in connection with such distribution, whether directly
  137. (as in payment for a copy of the Program) or indirectly (as in payment
  138. for some service related to the Program, or payment for some product
  139. or service that includes a copy of the Program "without charge";
  140. these are only examples, and not an exhaustive enumeration of prohibited
  141. activities). However, the following methods of distribution involving
  142. payment shall not in and of themselves be a violation of this restriction:
  143.  
  144.  
  145. (i) Posting the Program on a public access information storage and
  146. retrieval service for which a fee is received for retrieving information
  147. (such as an on-line service), provided that the fee is not
  148. content-dependent (i.e., the fee would be the same for retrieving the same
  149. volume of information consisting of random data).
  150.  
  151.  
  152.  
  153. (ii) Distributing the Program on a CD-ROM, provided that the files
  154. containing the Program are reproduced entirely and verbatim on such
  155. CD-ROM, and provided further that all information on such CD-ROM be
  156. redistributable for non-commercial purposes without charge.
  157.  
  158.  
  159.  
  160. Everything in this distribution must be kept together, in original
  161. and unmodified form.
  162.  
  163.  
  164.  
  165.  
  166. Limitations.
  167.  
  168. THE PROGRAM IS PROVIDED TO YOU "AS IS," WITHOUT WARRANTY. THERE IS NO
  169. WARRANTY FOR THE PROGRAM, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
  170. LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
  171. PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE ENTIRE
  172. RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD
  173. THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
  174. SERVICING, REPAIR OR CORRECTION.
  175.  
  176.  
  177.  
  178. IF YOU DO NOT ACCEPT THIS LICENCE, YOU MUST DELETE ALL FILES CONTAINED IN
  179. THIS ARCHIVE.
  180.  
  181. _____________________________________________________________________________
  182.  
  183. Thomas,
  184.  
  185.     October 1997
  186.  
  187.  
  188. ============================= Archive contents =============================
  189.  
  190. Original  Packed Ratio    Date     Time    Name
  191. -------- ------- ----- --------- --------  -------------
  192.      208     179 13.9% 14-Oct-97 19:38:26 +AllocP
  193.     4405    1511 65.6% 14-Oct-97 19:38:32 +AllocP.asm
  194.     6943    3063 55.8% 14-Oct-97 19:44:16 +AllocP.readme
  195.      856     377 55.9% 11-Oct-97 12:00:42 +AllocP.readme.info
  196. -------- ------- ----- --------- --------
  197.    12412    5130 58.6% 16-Oct-97 04:01:50   4 files
  198.